上一篇的[如何提升系統品質-Day3]重構– DRY & Top-Down思考方式(1)文章因為篇幅限制，所以這一篇會將最後的幾個步驟完成，並看到重構後的程式碼。

[如何提升系統品質]系列文章連結
步驟四：
接著來大風吹囉，先將原本屬於business logic的方法，移到Service裡面的AuthenticationService中。將屬於DataAccess的方法，移至DataAccess的AuthenticationDao中。會發現，原本在同一頁的方法，在Service中找不到他的兄弟了。


所以我們要在Service中，加上Dao類別的初始化，換呼叫Dao類別的方法。頁面也要修改成，呼叫AuthenticationService的VerifyPasswordById的方法。


到這邊，該共用的部分，我們都已經移至App_Code相對應的folder裡面。到現在，我們的程式邏輯還是沒變過。我們只有移動了位置，讓各功能模組的職責定位更加清楚。也可以讓團隊開發的時候，可以知道哪一些東西該去哪邊找，進而訂定coding standard。

步驟五：
回到我們新增的需求中，我們到現在還是只有一堆throw new NonImplementationException()，但是我們不用重複開發一樣的程式了。在VerifyPassword的部分，我們只需要呼叫AuthenticationService的VerifyPasswordById的方法即可。當回傳的是Passed時，我們這個方法即回傳true，其他則都當作驗證有誤。這就是基本的DRY原則，我們不重複開發一樣的東西，並不只是為了現在重複開發的成本，而是不遺留技術債給未來的人(那個人很有可能也是自己)。

其他的部分，我們就簡單的補上實作細節的內容：

一樣透過Top-Down的設計方式，再去產生對應的方法外殼即可，這樣做重點不只是省工，而是聚焦。

最後再加上try catch防呆，不讓user看到天書般的錯誤資訊，這是工程師基本的sense。

步驟六：
到步驟五這邊，基本上就大功告成了。但如果頁面有重複的使用到某一個class，而且代表的都是同一個職責，那我會建議再抽象化一層出來，避免重複的程式一再出現，所以我們會將使用到的class與初始化的部分再獨立出來。例如頁面用到兩次AuthenticationService，AuthenticationService用到兩次AuthenticationDao。我們將其封裝成property，避免重複初始化或是一式多份的情況發生。

大功告成！(重構完記得要慶祝一下！) 來看一下我們新的程式長的多乾淨：
原本的程式碼：

這一階段重構完成的結果：

圖太小的話，請見：
1.https://gist.github.com/cff41edd3dbefb0ebc39
2.http://pastie.org/2689089

結論
這篇文雖然有點冗長，但希望帶出來的觀念就是：
1.不要放縱自己，不要貪圖一時便宜，不要輕忽copy/paste帶來的技術債，不要因此讓自己扼殺了成長的機會。
2.抽象思考，不要被技術細節、實作細節所迷惑了，導致寫程式的過程像陷入漩渦的船，迷失了方向。
3.重構與Top-Down的開發方式，其實Visual Studio有很多工具可以用，只是端看各位願不願意嘗試與改變。

希望這一篇文章對大家在開發與維護上，可以有所幫助。